This brings them more in line with usage in pe_ipc_dispatch (I'm hoping
to condense all this code one day), and frees up the name "request" to
be used by pcmk__request_t in the future.

At the moment, this function is fairly unfortunately named (there's
already a process_lrmd_message).  However, the new function is gradually
going to be taking code from the old function until the old one is
completely gone.  So it's just a temporary confusion we'll need to live
with for a bit.

This new function holds the framework for handling commands with
pcmk__request_t instead of the old system.  It's a little tricky to
convert these commands over one at a time and still keep everything
working, which is why there's the big TODO comment.

Both places that call execd_process_message first add several additional
attributes to the request XML, so it makes sense to move that code into
execd_process_message instead.

Note that there are two different approaches to setting client->name if
it's missing.  I don't see why the attribute would ever be missing, so I
think it's safe to get rid of the lengthier approach that grabs the
client PID as a last option.

This commit is typical of how the commit for each command is going to
work:

* Expose a function in execd_commands.c to the rest of the exec daemon
  and give it a name that is consistent with "public" functions.

* Have it return a standard pacemaker return code.

* Remove the old handler block from process_lrmd_message (this is the
  older function, not the newer confusingly named function).

* Add a new handler function and add that function to the handler table.

...and rename them to make them consistent.  These are needed to handle
processing certain message types.

Handling this message type means we also need to send out a generic
notify message after sending the reply.  For the moment, the rc value
being passed to execd_send_generic_notify doesn't matter because
execd_process_rsc_register doesn't return anything (previously, it only
ever returned pcmk_ok).

Additionally, execd_process_rsc_exec should return a standard pacemaker
return code.  It doesn't do anything useful with the call_id value it
extracts and returns, and the caller already knows the call_id (and
doesn't do anything with the return value from execd_process_rsc_exec
aside from check if it's an error or not).

This additionally changes a couple functions to return a standard
Pacemaker return code.

This requires a little extra work, in addition to the steps of exposing
a function and changing its return type to be a standard Pacemaker
return code.

Sending a generic notify for unregistering a resource also requires
inspecting the return value, which we luckily have in the reply XML so
we can just grab it from there as needed.

Now that all messages are supported by the new code, we can add the
unknown message handler to catch anything else.  And that means
everything is being handled by execd_process_message now, so
process_lrmd_message can be removed.

Fixes T126

and rename the existing function to be execd_create_reply_as.  This gets
rid of the need to pass __func__ as the first argument every time.

Only a couple daemons send an ACK on an unknown request.  Those that do
send CRM_EX_INVALID_PARAM, which doesn't quite seem like the right
value.  I guess I can see what it's going for, but CRM_EX_PROTOCOL seems
like a better fit.